APPARATUS, METHOD AND SYSTEM FOR 
ACCELERATED GRAPHICS PORT BUS BRIDGES 

Specification 
CROSS REFERENCE TO RELATED APPLICATION 
5 This patent application is related to commonly owned U.S. Patent Application 

Serial No. 08/855,062; filed June 30, 1997; entitled "Apparatus, Method and System 
for Dual Accelerated Graphics Ports" by Ronald T. Horan, Gary W. Thome and 
Sompong P. Olarig, and is hereby incorporated by reference for all purposes. 

Background of the Invention 

10 Field of the Invention 

The present invention relates to computer systems using at least one bus 
bridge to interface with at least one central processing unit, a video graphics 
processor, random access memory and input-output peripheral devices together, and 
more particularly, in utilizing at least one bus bridge in a computer system to enable 
15 the computer system to interface with more than one input-output device of the same 
type. 

Description of the Related Technoiogy 

Use of computers, especially personal computers, in business and at home is 
becoming more and more pervasive because the computer has become an integral tool 
20 of most information workers who work in the fields of accounting, law, engineering, 
insurance, services, sales and the like. Rapid technological improvements in the field 
of computers have opened many new applications heretofore unavailable or too 
expensive for the use of older technology mainframe computers. These personal 
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computers may be used as stand-alone workstations (high end individual personal 
computers) or linked together in a network by a "network server" which is also a 
personal computer which may have a few additional features specific to its purpose in 
the network. The network server may be used to store massive amounts of data, and 
5 may facilitate interaction of the individual workstations connected to the network for 
electronic mail ("E-mail"), document databases, video teleconferencing, white 
boarding, integrated enterprise calendar, virtual engineering design and the like. 
Multiple network servers may also be interconnected by local area networks ("LAN") 
and wide area networks ("WAN"). 

10 A significant part of the ever-increasing popularity of the personal computer, 

besides its low cost relative to just a few years ago, is its ability to run sophisticated 
. programs and perform many useful and new tasks. Personal computers today may be 
easily upgraded with new peripheral devices for added flexibility and enhanced 
performance. A major advance in the performance of personal computers (both 
15 workstation and network servers) has been the implementation of sophisticated 
peripheral devices such as video graphics adapters, local area network interfaces, 
SCSI bus adapters, full motion video, redundant error checking and correcting disk 
arrays, and the like. These sophisticated peripheral devices are capable of data 
transfer rates approaching the native speed of the computer system microprocessor 
20 central processing unit ("CPU"). The peripheral devices' data transfer speeds are 
achieved by connecting the peripheral devices to the microprocessor(s) and associated 
system random access memory through high-speed expansion local buses. Most 
notably, a high speed expansion local bus standard has emerged that is microprocessor 
independent and has been embraced by a significant number of peripheral hardware 
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manufacturers and software progranuners. This high-speed expansion bus standard is 
called the "Peripheral Component Interconnect" or "PCI." A more complete 
defmition of the PCI local bus may be found in the PCI Local Bus Specification, 
revision 2.1; PCI/PCI Bridge Specification, revision 1.0; PCI System Design Guide, 
revision l.O; PCI BIOS Specification, revision 2.1, and Engineering Change Notice 
("ECN") entitled "Addition of "New Capabilities' Structure," dated May 20, 1996. the 
disclosures of which are hereby incorporated by reference. Hiese PCI specifications 
and ECN are available from the PCI Special Interest Group, P.O.Box 14070, 
Portland, OR 97214. 

A computer system has a plurality of information (data and address) buses 
such as a host bus, a memory bus, at least one high speed expansion local bus such as 
. the PCI bus, and other peripheral buses such as the Small Computer System Interface 
(SCSI), Extension to Industry Standard Architecture (EISA), and Industry Standard 
Architecture (ISA). The microprocessor(s) of the computer system communicates 
with main memory and with the peripherals that make up the computer system over 
these various buses. The microprocessor(s) communicates to the main memory over a 
host bus to memory bus bridge. The peripherals, depending on their data transfer 
speed requirements, are connected to the various buses which are comiected to the 
microprocessor host bus through bus bridges that detect required actions, arbitrate, 
and translate both data and addresses between the various buses. 

Increasingly sophisticated microprocessors have revolutionized the role of the 
personal computer by enabling complex applications software to run at mainframe 
computer speeds. The latest microprocessors have brought the level of technical 
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sophistication to personal computers that, just a few years ago, was available only in 
mainframe and mini-computer systems. Some representative examples of these new 
microprocessors are the "PENTIUM" and "PENTIUM PRO" (registered trademarks 
of Intel Corporation). Advanced microprocessors are also manufactured by Advanced 
Micro Devices, Cyrix, IBM and Motorola. 

These sophisticated microprocessors have, in turn, made possible running 
complex application programs using advanced three dimensional ("3-D") graphics for 
computer aided drafting and manufacturing, engineering simulations, games and the 
like. Increasingly complex 3-D graphics require higher speed access to ever-larger 
amounts of graphics data stored in memory. This memory may be part of the video 
graphics processor system, but, preferably, would be best (lowest cost) if part of the 
main computer system memory. Intel Corporation has proposed a low cost but 
improved 3-D graphics standard called the "Accelerated Graphics Port" (AGP) 
initiative. With AGP 3-D, graphics data, in particular textures, may be shifted out of 
the graphics controller local memory to computer system memory. The computer 
system memory is lower in cost than the graphics controller local memory and is more 
easily adapted for a multitude of other uses besides storing graphics data. 

The proposed Intel AGP 3-D graphics standard defines a high-speed data 
pipeline, or "AGP bus," between the graphics controller and system memory. This 
AGP bus has sufficient bandwidth for the graphics controller to retrieve textures from 
system memory without materially affecting computer system performance for other 
non-graphics operations. The Intel 3-D graphics standard is a specification that 
provides signal, protocol, electrical, and mechanical specifications for the AGP bus 
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and devices attached thereto. This specification is entitied "Accelerated Graphics Port 
Interface Specification version 2.0," dated May 4, 1998; and also "Accelerated 
Graphics Port Interface Specification version 1.0," dated July 31, 1996 are hereby 
incorporated by reference. The AGP specification, both versions 2.0 and 1.0, are 
available from Intel Corporation, Santa Clara, California. 

The AGP interface specification uses the 66 MHz PCI (Revision 2.1) 
specification as an operational baseline, with three performance enhancements to the 
PCI specification which are used to optimize the AGP specification for high 
performance 3-D graphics applications. These enhancements are: 1) pipelined 
memory read and write operations, 2) de-multiplexing of address and data on the AGP 
bus by use of side-band signals, and 3) data tiansfer rates of 133 MHz for data 
tiiKJUghput in excess of 500 megabytes per second ("MB/s"). The remaining 
AGP specification does not modify tiie PCI specification, but rather provides a range 
of graphics-oriented performance enhancements for use by 3-D graphics hardware and 
software designers. The AGP specification is neither meant to replace or diminish fiill 
use of the PCI standard in the computer system. The AGP specification creates an 
independent and additional high speed local bus for use by 3-D graphics devices such 
as a graphics contiroUer, wherein tiie other input-output ("I/O") devices of the 
computer system may remain on any combination of tiie PCI, SCSI, EISA and ISA 
buses. 

To fimctionally enable tiiis AGP 3-D graphics bus, new computer system 
hardware and software are required. This requires new computer system core logic 
designed to function as a host bus/memory bus/PCI bus to AGP bus bridge meeting 
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the AGP specification, and new Read Only Memory Basic Input Output System 
("ROM BIOS") and Application Programming Interface ("API") software to make the 
AGP dependent hardware functional in the com-'ter system. The computer system 
core logic must still meet the PCI standards referenced above and faciUtate interfacing 
5 the PCI bus(es) to the remainder of the computer system. In addition, new AGP 
compatible device cards must be designed to properly interface, mechanically and 
electrically, witii the AGP bus connector. A suitable computer system employing tiie 
AGP specification is shown in Figure 1. The prior art computer system has at least 
one central processing unit 102 connected to a host bus 103 which, in turn, is 
10 connected to a core logic 104. The core logic 104 is a chipset of components for 
linking tiie system random access memory 106 via tiie memory bus 105 to tiie host 
bus 103 and the primary PCI bus 109 through DRAM control 202. The core logic 104 
als^ contains the circuitry related to tiie AGP bus 107, such as AGP to memory bridge 
204 and tiie PCI to memory bridge 212. An AGP-compliant device, such as tiie video 
15 graphics controller 1 10, is comiected to tiie AGP bus 107. In tiiis example, a video 
display 112 is connected to tiie video graphics controUer 110. Various otiier I/O 
devices 101 are connected to the primary PCI bus 109. 

Botii AGP bus transactions and PCI bus transactions may be run over the AGP 
interface. An AGP master (graphics) device may tiransfer data to system memory 
20 using eitiier AGP transactions or PCI ti-ansactions. The core logic 104 can access tiie 
AGP master device only witii PCI transactions. Traffic on tiie AGP interface may 
consist of a mixture of interleaved AGP and PCI transactions. The access request and 
data queue structures are illustrated in Figure 2. 



349204 



6 



CP1618 



AGP transactions are run in a split transaction fashion where the request for 
data transfer is "disconnected" from the data transfer itself. The AGP master initiates 
an AGP transaction with an access request. The core logic 104 responds to the access 
request by directing the corresponding data transfer at a later time. The fact that the 

5 access requests are separated from the data transfers allows the AGP master to issue 
several access requests in a pipelined fashion while waiting for the data transfers to 
occur. Pipelining access requests results in having several read and/or write requests 
outstanding in the core logic's request queue 208 (within the AGP to memory bridge 
204) at any point in time. The request queue 208 is divided into high priority and low 

10 priority sub-queues (not shown), each of which deal with respective accesses 
according to separate priority and ordering rules. The AGP master tracks the state of 
the request queue in order to limit the number of outstanding requests and identify 
data transactions. 

The core logic 104 processes the access requests present m its request queue 
15 208. Read data will be obtained from system memory 106 and returned at the core 
logic's initiative via the read data retum queue 206. Write data will be provided by 
the AGP device at the core logic's direction when space is available in the core logic's 
write data queue 210. Therefore, AGP transaction traffic will generally consist of 
interleaved access requests and data transfers. 

20 All PCI transactions on the AGP have their own queues ~ separate from the 

AGP transaction queues. Each queue has its own access and ordering rules. Not 
shoAvn in Figure 2 is the core logic queue which handles processor accesses directly to 
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the PCI target interface 238 of the AGP maste-, all of which are executed as non- 
pipelined PCI bus transactions. 

On the other end of the AGP bus 107, the AGP-compliant device (e.g., video 
graphics controller 110 in Figure 1) has an AGP interface 230 with read data return 

5 queue 232, read/write request queue 234, and write data queue 236 that correspond to 
the read data return queue 206, read and write request queue 208, and write data queue 
210 of the AGP to memory bridge 204 within the core logic 104. The AGP-compliant 
device also has a PCI target interface 238. The queues within the AGP interface 230 
and the PCI target interface 238 are connected to the data source/sink 239 of the 

10 device. 

AGP and PCI device cards are not physically or electrically interchangeable 
even though there is some coixunonality of signal functions between the AGP and PCI 
interface specifications. The present AGP specification only makes allowance for a 
single AGP device on an AGP bus. Whereas the PCI specification allows two PCI 

15 devices on a PCI bus running at 66 MHz. The single AGP device is capable of 
functioning in both a Ix mode (264 MB/s peak) and a 2x mode (532 MB/s peak). The 
AGP bus is defined as a 32-bit bus, or four b>'tes per data transfer. The PCI bus is 
defmed as either a 32 bit or 64 bit bus, or four or eight bytes per data transfer, 
respectively, the AGP bus, however, has additional side-band signals which enables 

20 it to transfer blocks of data more efficiently than is possible using a PCI bus. 

An AGP bus mnning in the 2x mode provides sufficient video data throughput 
(532 MB/s peak) to allow increasingly complex 3-D graphics applications to run on 
personal computers. Some personal computer uses do not require high end 3- 
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D graphics, but would greatly benefit from having an additional AGP card slot for 
accepting an additional input-output device such as another video graphics card (dual 
head monitors), a high speed network interface card ("NIC"), a SCSI adapter, a wide 
area network digital router, and the like. Since the AGP specification is comprised of 
a superset of the 66 MHz, 32 bit PCI specification, a PCI device may also function on 
the AGP bus (different card slot connectors for the AGP and PCI device cards would 
be necessary). Thus, embedded (directly connected to the computer system 
motherboard) or card slot pluggable AGP and PCI devices could share the same 
AGP/PCI bus, controller and arbiter of a core logic chipset used in a computer system. 

What is needed is a computer system that can accommodate more than one 
AGP-compatible device and that has increased bandwidth to accommodate the 
. increased number of AGP-compatible devices. 
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Summary of the Invention 
The present invention overcomes the above-identified problems as well as 
other shortcomings and deficiencies of existing technologies by providing in a 
computer system an AGP to AGP bridge that is capable of linkmg one or more AGP- 

5 compatible devices to a standard AGP bus that is connected to a standard AGP- 
compatible core logic chipset. Specifically, the present invention provides a computer 
system having at least one central processing unit, system memory, and a core logic 
capable of accepting an AGP bus. An AGP to AGP bridge is also provided that is 
connected to the standard AGP bus of the core logic. The AGP to AGP bridge can 

10 accommodate two or more AGP-compatible devices that can be accessed through the 
standard AGP bus via the AGP to AGP bridge. A PCI to memory bridge is also 
provided within the core logic that is connected to the AGP bus so that PCI devices 
may be connected to the AGP to AGP bridge and communicate with the core logic. 
The AGP to AGP bridge is fitted with an overall flow control logic that controls the 

15 transfer of data to or firom the various AGP devices and the standard AGP bus that is 
connected to the core logic of the computer system. 

In the preferred embodiment of the present invention, the AGP to AGP bridge 
has a second AGP bus and a third AGP bus. If more than two buses are present on the 
AGP to AGP bridge, then the control of the intemal, multiple FIFOs is managed by 
20 having a data flow pointer that keeps track of how many bytes of the returning read 
data belong to which AGP device. The AGP to AGP bridge of the present mvention 
can utilize a standard 32-bit AGP bus. Furthermore, the AGP to AGP bridge can be 
constructed as a 64-bit bus that is bifiircated into two (dual) 32-bit buses in order to 
enhance bandwidth. The latter embodiment allows the dual primary AGP buses to 
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work directly with the standard (32-bit) AGP chipset To the core logic chipset, each 
AGP bus behaves fully as a standard AGP device but can operate concurrently. This 
allows each AGP device to have its own private bus and to run at maximum speed 
concurrently. Another advantage of this altemate embodiment is that it can support 
5 any number of AGP devices/slots on the secondary AGP buses. 

In yet another altemate embodiment of the present invention, the dual 32-bit 
buses can be combined to form a single 64-bit bus to increase the available 
bandwidth. In this altemate embodiment, the AGP to AGP bridge can be an external 
application specific integrated circuit (ASIC) that interfaces directly with the standard 

10 AGP core logic chipset. To the core logic chipset, the AGP to AGP bridge behaves 
fully as a superset of the standard 32-bit AGP device. This allows doubling of the bus 
bandwidth without running the bus at higher clock frequencies, i.e. 2 x 66 MHz. 
Currently, most AGP devices could not meet the AC timing at 66 MHz. Therefore, 
this altemate embodiment is the only viable solution for doubling the bus bandwidth 

15 without running the bus at 133 MHz. In yet another altemate embodiment, the AGP 
to AGP bridge can accommodate the single 64-bit AGP bus (connected to a special 
64-bit core logic chipset) for increased performance. 

In yet another altemate embodiment of the present invention, the AGP to AGP 
bridge acts as a bus repeater and allows the AGP to AGP bridge to work with standard 
20 "off-the-shelf bi-directional transceivers or FIFOs. The altemate embodiment 
enables the AGP bus to be extended, thus allowing the computer system to support 
more than one AGP device/slot. However, this altemate embodiment adds additional 
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latency to all the bus transactions and requires the core logic chipset to control the 
data flow from both directions. 

Other and further features and advantages will be apparent from the following 
description of presently preferred embodiments of the invention, given for the purpose 
5 of disclosure and taken in conjunction with the accompanying drawings. 

Brief Description of the Drawings 
Figure 1 is a block diagram of a prior art computer system; 

Figure 2 is a block diagram of a prior art AGP device interface with the core 
logic of a computer system; 

10 Figure 3 is a block diagram of a computer system of the present invention; 

Figure 4a is a block diagram of an embodiment of the AGP to AGP bridge of 
the present invention; 

Figure 4b is a block diagram of the preferred embodiment utilizing the AGP to 
AGP bridge of the present invention; 

15 Figure 4c is a block diagram of an alternate embodiment utilizing the AGP to 

AGP bridge of the present invention; 

Figure 4d is a block diagram of an altemate embodiment utilizing the AGP to 
AGP bridge of the present invention; 

Figure 4e is a block diagram of the preferred embodiment of the AGP to AGP 
20 bridge of the present invention; 
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Figure 5 is a block diagram of the PCI to PCI bridge of the present invention; 

Figure 6 is a flowchart of the function of the Second AGP Bus Request 
Interface of the present mvention; 

Figure 7 is a flowchart of the function of the Second AGP Bus Reply Interface 
5 of the present invention; 

Figure 8 is a flowchart of the function of the Third AGP Bus Request Interface 
of the present invention; 

Figure 9 is a flowchart of the function of the Third AGP Bus Reply Interface 
of the present invention; 

10 Figure 10 is a flowchart of the function of the First AGP Bus Request Interface 

of the present invention; 

Figure 11 is a flowchart of the function of the First AGP Bus Reply Interface 
of the present invention; 

Figure 12 is a block diagram showing the state machines within the Control 
15 Flow Logic of the present invention; 

Figure 13 is a flowchart for the first state machine within the Flow Control 
Logic of the present invention; 

Figure 14 is a flowchart for the second state machine within the Flow Control 
Logic of the present invention; 
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Figure 15 is a flowchart for the third state machine within the Flow Control 
Logic of the present invention; 

Figure 16 is a block diagram of an alternate embodiment of the present 
invention; 

5 Figure 17 is a flowchart for peer-to-peer enabled requests of the second AGP 

read and write request queue; 

Figure 18 is a flowchart for peer-to-peer enabled requests of the third AGP 
read and vso-ite request queue; 

Figure 19 is a flowchart for peer-to-peer replies m the second AGP read and 
10 write request queue; 

Figure 20 is a flowchart for peer-to-peer replies in the third AGP read and 
write request queue. 

Figure 21 is a flowchart for peer-to-peer write request in the second AGP write 
data queue; and 

15 Figure 22 is a flowchart for peer-to-peer wxite requests in the third AGP write 

data queue. 
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Detailed Description of the Preferred Embo diments 
The present invention is an apparatus, method and system for providing an 
AGP to AGP bus in a computer system that is capable of allowing multiple AGP 
devices to be connected to a single AGP bus on a core logic chipset. 

5 The AGP bus was developed to have sufficient data bandwidth for a video 

controller in a computer system, up to 532 megabytes per second ("MB/s"), to run 
increasingly complex three dimensional ("3-D") graphics applications such as, for 
example, games and engineering simulations. Not all computer applications, 
however, require the capability of running 3-D graphics at 532 MB/s, but would 

10 greatly benefit by having an additional AGP card slot or PCI card slot for another 
video graphics card, a high speed NIC, a SCSI adapter, a wide area network digital 
router, or the like. Computers used as network servers or workstations would greatly 
benefit by having the ability to use two AGP devices, or an AGP device and a PCI 
device at a combined data transfer rate of 532 MB/s or 264 MB/s per device. In 

15 addition, disclosed hereinbelow is an embodiment of the present invention that is 
capable of data transfer rates of 532 MB/s for each AGP device. 

For illustrative purposes, preferred embodiments of the present invention are 
described hereinafter for computer systems utilizing the Intel x86 microprocessor 
architecture and certain terms and references will be specific to that processor 
20 platform. AGP and PCI are interface standards, however, that are hardware 
independent and may be utilized with any host computer designed for these interface 
standards. It will be appreciated by those skilled in the art of computer systems that 
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the present invention may be adapted and applied to any computer platform utilizing 
the AGP and PCI interface standards. 

The PCI specifications referenced above are readily available and are hereby 
incorporated by reference. The AGP specification referenced above is readily 

5 available from Intel Corporation, and is hereby incorporated by reference. Further 
definition and enhancement of the AGP specification version 1.0 referenced above is 
more fully defined in "Compaq's Supplement to the 'Accelerated Graphics Port 
Interface Specification Version 1.0'," Revision 0.8, dated April 1, 1997, and was 
included in commonly owned co-pending U.S. Patent Application Serial No. 

10 08/853,289, filed May 9, 1997, entitled "Dual Purpose Apparatus, Method and System 
for Accelerated Graphics Port and Peripheral Component Interconnect" by Ronald T. 
Hor^ and Sompong P. Olarig, and which is hereby incorporated by reference. 

Referring now to the drawings, the details of preferred embodiments of the 
present invention are schematically illustrated. Like elements in the drawings will be 

15 represented by like numbers, and similar elements will be represented by like numbers 
with a different lower case letter suffix. Referring now to Figure 3, a schematic block 
diagram of a computer system utilizing the present invention is illustrated. A 
computer system is generally indicated by the numeral 100 and comprises a central 
processing unit 102 ("CPU"), core logic 104, system random access memory 106 

20 ("RAM"), a video graphics controller 110, a local firame buffer 108, a video display 
112, a PCI/SCSI bus adapter 114, a PCI/EISA/ISA bridge 116, and a PCI/IDE 
controller 118. Multiple video graphics controllers 110, local fi-ame buffers 108 and 
video displays 1 12 can be added to the added to the computer system 100. Single or 
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multilevel cache memory (not illustrated) may also be included in the computer 
system 100 according to the current art of microprocessor computer systems. The 
central processing unit 102 may be a plurality of CPUs 102 in a symmetric or 
asymmetric multi-processor configuration. 

The central processing unit 102 is connected to the core logic 104 through a 
host bus 103. The system RAM 106 is connected to the core logic 104 through a 
memory bus 105. The video graphics contK)ller(s) 1 10 is connected to the core logic 
104 through the first AGP bus 107. The video graphics controller 110 is an AGP- 
compatible device in that it is capable of being connected to and accept/write 
messages fi-om/to the first AGP bus 107. Video graphics controllers are not the only 
devices that are AGP-compatible. Other devices, such as a second I/O device 166 
may have this capability. In the preferred embodiment of the present invention, two 
AGP devices may be connected to AGP to AGP bridge 160. In the preferred 
embodiment of the present invention, the AGP to AGP bridge 160 is an appUcation 
specific integrated circuit (ASIC) that interfaces directly with the standard AGP 
chipset 104. To the core logic 104 chipset, the AGP to AGP bridge 160 behaves fully 
as a standard AGP device. Therefore, the 32-bit version of the AGP to AGP bridge 
160 of the present invention does not require any special side-band control signals 
other than the standard AGP bus protocol as would be required by a bus repeater. 
However, the 64-bit version of the AGP to AGP bridge 160 of the present invention 
would require a special side-band control signal. Finally, in an alternate embodiment 
of the present invention, a bus repeater could be substituted for the AGP to AGP 
bridge 160. 
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In the preferred embodiment of the present invention, the AGP to AGP bridge 
160 links two AGP buses to the first AGP bus 107. This allows the control of the 
internal FIFOs to be simplified. An intemal arbiter in the flow control logic 260 (see 
Figure 4a) can keep track of the outstanding requests on the prunary (first) AGP bus 
based upon the currently active bus grant signal. However, in an alternate 
embodiment of the present invention, the AGP to AGP bridge 160 may be expanded 
to include any nimiber of AGP buses for each AGP to AGP bridge 160, such as a 
fourth AGP bus 168 as shown in Figure 3. In this alternate embodiment, the control 
of the intemal multiple FIFOs can be managed by having a data flow pointer within 
the flow control logic 260 that keeps track of how many bytes of the returning read 
data belong to which AGP device. In either embodiment, by linking the AGP to AGP 
bridge 160 to the first AGP bus 107, the trace length between the AGP device and the 
core logic 104 is increased moderately. However, the point-to-point lengths (e.g., 
between the core logic 104 and the first AGP interface target and arbiter 248 is 
reduced, thereby allowing the AGP devices to run at a higher (or maximum) clock 
fi-equency. This configuration allows each AGP port to run at its maximum speed 
without additional electrical loading while maintaining signal integrity. Furthermore, 
use of the AGP to AGP bxis 160 allows the AGP devices attached thereto to reside 
farther away, physically, from the core logic 104 (i.e., the motherboard) that was 
heretofore possible, enabling a wider range of choices for the physical configuration 
of the computer system. 

Alternatively, the preferred embodiment of the AGP to AGP bridge 160 (i.e., 
one that connects two AGP buses to the standard single AGP bus), may be connected 
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to other AGP to AGP bridges 160 in a tree like structure in order to obtain the desired 
number of AGP devices 166 as shown in Figure 16. 

In yet another alternate embodiment of the present invention, the AGP to AGP 
bridge is replaced with a bus repeater. In this embodiment, the bxis repeater utilizes 

5 "off-the-shelf bi-directional transceivers or FIFOs. This alternate embodiment 
enables an even wider range of choices for the physical placement of the AGP 
devices, which can be located remotely from the core logic unit and allows the 
computer system to support more than one AGP device/slot. However, this alternate 
embodiment adds additional latency to all the bus transactions and reqmres the core 

10 logic chipset to control the data flow from both directions. 

As shown in Figure 3, The PCI/SCSI bus adapter 114, PCI/EISA/ISA bridge 
116, and PCI/IDE controller 118 are connected to ttie core logic 104 through a 
primary PCI bus 109. Also connected to the PCI bus 109 are a network interface card 
122 ("NIC") and a PCI/PCI bridge 124. Some of the PCI devices such as the NIC 122 
15 and PCI/PCI bridge 124 may plug into PCI connectors on the computer system 100 
motherboard (not illustrated). 

Again referring to Figure 3, hard disk 130 and tape drive 132 are connected to 
the PCI/SCSI bus adapter 1 14 through a SCSI bus 1 1 1. The NIC 122 is connected to 
a local area network 1 19. The PCI/EISA/ISA bridge 1 16 connects over an EISA/ISA 
20 bus 1 13 to a ROM-BIOS 140, non-volatile random access memory 142 ("NVRAM"), 
modem 120, and input-output controller 126. The modem 120 connects to an 
telephone line 121. The input-output controller 126 interfaces with a keyboard 146, 
real-time clock 144 ("RTC"), mouse 148, floppy disk drive 150 ("FDD"), as well as 
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serial port 152 and parallel port 154. A CD ROM drive 134 and a disk drive 128 can 
be connected to PCI/IDE controller 118. The EISA/ISA bus 113 is a slower 
information bus than the PCI bus 109, but it costs less to interface with the EISA/ISA 
bus 113. 

AGP, being a superset of PCI, uses the PCI signals along with some side band 
signals in order to operate. The AGP side band signals are PIPE#, RBF#, and 
ST[2:0]. The optional AGP signals are side-band address ports SBA[7:0], 
AD_STB[1:0], and SB_STB. The above-mentioned signals can be used for 
performance enhancements, such as 2x (double-speed) mode and side-band 
addressing. The AGP-compliant device must also be a PCI slave (although PCI 
master status is optional). The use of side-band signaling enables the transfer of data 
on both the rising and falling edge of the clock cycle, effectively doubling the data 
transfer rate. The AGP-compliant device ("AGP device") is an AGP master only, and 
the core logic 1 04 acts as an AGP target only. 

In the preferred embodiment of the present invention, the first AGP bus 107 is 
a standard 32-bit bus. However, in an alternate embodiment of the present invention, 
the AGP bus 107 may consist of a 64-bit bus that acts as two dual 32-bit AGP buses. 
An alternate embodiment of the AGP to AGP bridge 160 of the present invention can 
utilize the dual 32-bit buses to enhance bandwidth, or, alternatively, the preferred 
embodiment of the AGP to AGP bridge 160 of the present invention can be fitted onto 
each of the dual 32-bit AGP buses, thereby allowing secondary and tertiary AGP 
buses. This alternate embodiment allows the dual primary AGP buses to work 
directly with the standard AGP chipset. To the core logic chipset, each AGP bus 
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behaves fiilly as a standard AGP device but can operate concurrently. This allows 
each AGP device to have its own private bus and to run at maximum speed 
concurrently. Another advantage of this alternate embodiment is that it can support 
any number of AGP devices/slots on the secondary AGP buses. 

5 In yet another alternate embodiment of the present invention, the 64-bit bus is 

not bifurcated. Instead, the 64-bit bus is utilized (with a special core logic chipset) to 
increase the available bandwidth. In this alternate embodunent, the AGP to AGP 
bridge can be an external ASIC that interfaces directly with the standard AGP core 
logic chipset. To the core logic chipset, the AGP to AGP bridge behaves fully as a 

10 superset of the standard 32-bit AGP device. This allows doubling of the bus 
bandwidth without running the bus at higher clock frequencies, i.e. 2x 66 MHz. 
. Currently, most AGP devices may not meet the AC timing at 66 MHz. Therefore, this 
alternate embodiment may be the only viable solution for doubling the bus bandwidth 
without running the bus at 133 MHz. An alternate embodiment of the AGP to AGP 

15 bridge can accommodate the single 64-bit AGP bus for increased performance. 

In yet another embodiment of the present invention, the first AGP bus 107 is a 
64-bit bus that is utilized as a single 64-bit AGP bus. The 64-bit bus provides 
additional data bandwidth for the agent or system that requires it. In this alternate 
embodiment, the AGP to AGP bridge 160 can be an external ASIC that interfaces 
20 directly with the core logic 104 witiiout requiring modification of the core logic 104. 
To tiie core logic 104, tiie AGP to AGP bridge 160 witii the 64-bit AGP bus 107 
behaves as a superset of the standard 32-bit AGP device. This alternate embodiment 
allows the doubling of the bus bandwidth witiiout running the bus at higher clock 
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frequencies, i.e., the effective bandwidth is twice that of the current 66 MHz clock 
speed. This relieves the necessity of running the fnst AGP bus 107 at 133 MHz to 
obtain acceptable bandwidth. 

When running the two 32-bit buses as a single 64-bit bus, the following 
5 signals are needed for 64-bit operation. Request (REQ64#), ACK64#, C/BE[7:4]#, 
AD[63:32], and ST[3:2]. In this scenario, the 64-bit agent must default to 32-bit 
mode unless a 64-bit transaction is negotiated. Since there is only one AGP device 
supported by the standard core logic 104 chipset, the 64-bit bus transaction can be 
statically negotiated during POST. REQ64# can be drive low by the AGP 64-bit 
10 master and ACK64# can be asserted low by the 64-bit device target. This situation is 
vinlike the PCI which are dynamically negotiated once per transaction between the 
master and the target. If REQ64# and ACK64# are not both active, then the standard 
32-bit AGP bus operation is performed instead of the 64-bit bus operation. Both 
REQ64# and ACK64# are externally pulled up to ensure proper behavior when 
15 mixing 32-bit and 64 bit agents if multiple AGP agents are supported. 

Although there is no ordering relationship between AGP and PCI, the AGP 
specification does have some ordering requirements. First, the AGP-compUant target 
must return read data in the same order as it was requested. Second, AGP write 
operations are processed by the AGP-compliant target in the order in which they are 
20 requested. Third, read data that is returned will be coherent with previously issued 
AGP write requests. Fourth, an AGP write may bypass one or more previously issued 
AGP read operations. The fifth requirement is that PCI transactions initiated by an 
AGP-compliant master or AGP-compliant target must follow the ordering rules 
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specified in the PCI specification. Sixth, high priority reads and writes have the 
highest priority for memory services. Seventh, an AGP flush command will return 
after all previous low priority and high priority write commands have been completed. 
The fmal requirement is that an AGP fence command forces write commands after 
itself in order not to pass any read commands before itself 

The system architecture of the AGP to AGP bridge 160 of the present 
invention is shown in Figure 4a. The AGP to AGP bridge 160, in support of the AGP 
specification, has a PCI interface 161, with the remainder of the bridge 160 being 
devoted to AGP-related transactions. The PCI interface 161 is connected to the furst 
interface target and arbiter 248. The PCI interface 161 is also connected to the second 
interface target and arbiter 258 and to the third interface target and arbiter 278. 
Because there are no ordering requirements between the PCI and the AGP 
transactions, the PCI and the AGP sections can act independently of each other. The 
AGP to AGP bridge 160 of the present invention therefore allows other I/O 
controllers to take advantage of the AGP bus in systems that are not fully utilizing the 
AGP bus bandwidth. 

Figure 4a shows two AGP buses, the second AGP bus 162 and the third AGP 
bus 164, both being bridged into a single first AGP bus 107. The first AGP bus 107 is 
connected to the core logic 104. Each bus has a read/write request queue, a read data 
return queue, and a write data queue. As mentioned before, AGP transactions are split 
transactions. Read and write requests are queued up initially and then each request is 
serviced one-by-one according to the ordering relationship mentioned above. The 
AGP to AGP bridge 160 is a target on the second AGP bus 162 and the thurd AGP bus 
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164. Consequently, an arbiter is required for the second AGP bus 162 and the third 
AGP bus 164. The AGP to AGP bridge 160 is a master on the first AGP bus 107. 

In the preferred embodiment of the present invention, the AGP to AGP bridge 
160 of the present invention has three sets of AGP interfaces, each of which contains 
three queues. As per the AGP specification, the first AGP interface 240 has a first 
read data return queue 242, first read and write request queue 244, and a first write 
data queue 246. The first read data return queue 242 must have a minimum of 72 
bytes. In the preferred embodiment of the present mvention, the furst read data return 
queue should have 296 bytes to ensure adequate performance. Of the 296 bytes, 40 
bytes should be reserved for RBF# (Read Buffer Full) spUlover. The RBF# spillover 
is to be used when the master mterface on the first AGP bus 107 has asserted an RBF# 
after the target has initiated a response. In this case, the master must have a few bytes 
of buffer space in order to receive the read data from the target. This is for 
compliance with the AGP specification, which requires that a generic AGP device 
must have 40 bytes of buffer space available for this purpose. 

The first AGP interface 240 is of conventional design so that, to the first AGP 
bus 107, the AGP to AGP bridge 160 appears to be just a standard AGP device and is 
thus treated as such. Furthermore, the AGP to AGP bridge 160 card fits into a 
standard AGP port that is connected to the first AGP bus 107. This enables any 
computer system with an AGP-compatible core logic and AGP port to accommodate 
the present invention without any hardware changes whatsoever. 

The first AGP interface 240 is connected to the second AGP interface 250 and 
the third AGP interface 270 as shown in Figure 4a. The second AGP interface 250 is 
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connected to the second interface target and arbiter 258. Similarly, the third interface 
target and arbiter 278 is connected to tlie third AGP interface 270. The second AGP 
interface 250 has a second read data return queue 252, a second read and write request 
queue 254, and a second write data queue 256 that correspond to the three queues in 

5 the first AGP interface 240. The second read data return queue 252 must have a 
minimum of 32 bytes. The third AGP interface 270 has a third read data retum queue 
272, a third read and write request queue 274, and a third write data queue 276. The 
third read data retum queue 272 must have a minimum of 32 bytes. The second read 
data retum queue 252 is connected to the first read data retum queue 242. Similarly, 

10 the third read data retum queue 272 is also connected to the first read data retum 
queue 242 as shown in Figure 4a. Likewise, the second read and write request queue 
254 and the third read and write request queue 274 are both connected to the first read 
and write request queue 244. Finally, the second write data queue 256 and the third 
write data queue 276 are connected to the first write data queue 246. The first write 

15 data retum queue 246, the second write data retum queue 256, and the third write data 
retum queue 274 all must have a minimum of 64 bytes available because 64 bytes is 
the size of the longest write on an AGP bus. All of the elements within the AGP to 
AGP bridge 160, with the sole exception of the PCI interface 161, are connected to 
the flow control logic 260 as shown in Figure 4a. The PCI interface 161 is an 

20 intermediary that connects the first AGP interface. The fimction of the flow control 
logic 260 will be explained below. 

Figure 4b shows a block diagram of the preferred embodiment of the present 
invention, wherein the AGP to AGP bridge 160 (as shown in Figure 4a) connects a 
geometry processor 302 and a rendering processor 304 to the first AGP bus 107. A 



349204 



CP1618 



geometry processor is used to generate triangles and geometric vertices. The output 
of the geometry processor 302 is then passed to the rendering processor 304 which 
performs post processing and forwards the resultant information to the graphics 
display (e.g., a monitor or screen). In the typical scenario, the geometry processor 302 
obtains raw data from the CPU 102 or the system memory 106 via the core logic 104, 
the AGP bus 107, and the AGP to AGP bridge 160. Similarly, the rendering 
processor 304 receives texture data (typicaUy from the system memory 106) via the 
AGP to AGP bridge 160. As shown in Figure 4b, the geometry processor 302 is 
connected to the AGP to AGP bridge 160 via the second AGP bus 162. Similarly, the 
rendering processor 304 is connected to the AGP to AGP bridge 160 via the third 
AGP bus 164. A separate connection between the second AGP Request and Data 
Queues 252 and the third AGP Request and Data Queues 270 is included in the 
present invention as shown in Figure 4b. The separate connection between second 
AGP Request and Data Queues 252 and the third AGP Request and Data Queues 270 
enables direct transfer of geometric vertices and other data from the geometry 
processor 302 to the rendering processor 304 without tying up bandwidth or other 
resources outside of the AGP to AGP bridge 160. Furthermore, if necessary, the 
overall flow control logic 260 can enable information to be transferred to both the 
geometry processor 302 and the rendering processor 304 simultaneously. More 
importantly, however, the geometry processor 302 can communicate with the 
rendering processor 304 without having to go through the core logic 104. This 
relieves the control logic 104 to perform other tasks, thereby increasing the overall 
performance of the computer system. More detail of the preferred embodiment of the 
AGP to AGP bridge can be fovmd later in the discussion of Figure 4e. 
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An alternate embodiment of the present invention is illustrated in Figure 4c. 
In this embodiment, the AGP to AGP bridge 160, the geometry processor 302 and the 
rendering processor 304 all reside on a single printed circuit board (PCB) or PC card. 
This configuration enables a graphics intensive PC card to be built as a single unit and 
5 then plugged into the AGP bus 107. 

In yet another alternate embodiment of the present invention is illustrated in 
Figure 4d. In this alternate embodiment, the AGP to AGP bridge 160 is connected to 
the AGP bus 107 in the normal fashion. However, unlike the embodiment shown m 
Figure 4c, in this embodiment, the geometry processor 302 is embedded or resides on 

10 its own geometry processor board 303 which is a printed circuit board or PC card that 
is capable of accommodating a geometry processor board 303. Similarly, tiie 
. rendering processor 304 is embedded on its own rendering processor board 305 as 
shown in Figure 4d. As with the geometry processor board 303, the rendering 
processor board 305 is a printed circuit board or PC card that is capable of 

15 accommodating a rendering processor 304. This embodiment enables the geometry 
processor and the rendering processor to be upgraded or replaced separately, without 
affecting the rest of the computer system. In this alternate embodiment, the AGP to 
AGP bridge 160 does not reside on either the geometry processor board 303 or the 
rendering processor board 304. Instead, the AGP to AGP bridge 160 could reside on 

20 its own PCB or PC card, or it can be incorporated into the core logic chipset 104. 
This configuration, therefor, provides added flexibility. 

Figure 4e is a block diagram of the preferred embodiment of the AGP to AGP 
bridge of the present invention. The preferred embodiment AGP to AGP bridge 160 
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differs from the embodiment illustrated in Figure 4a in that the preferred embodiment 
accommodates peer to peer transfer between the geometry processor 302 and the 
rendering processor 304 (of Figure 4b). In order to accommodate peer-to-peer 
transfer, the second and third AGP interfaces have to be both a master and a target. 
However, according to the AGP specification, the device is always a master and the 
chipset is always a target. In the first embodiment of the AGP to AGP bridge 160 (see 
Figure 4a), standard AGP interfaces are used. For example the second AGP interface 
250 and the third AGP interface 270 were targets and the first AGP interface 240 was 
a master. 

In the preferred embodiment, the AGP to AGP bridge 160 (shown in Figure 
4e) is designed to enhance the support of peer-to-peer traffic. The queue blocks (252, 
. 254, and 256) of tiie second AGP interface 250 are all bi-directional. Similarly, the 
queue blocks (272, 274 and 276) of the third AGP interface 270 are also bi- 
directional. Each bi-directional queue consists of two mdependent queues, one for 
each direction of traffic. For instance, there is a second AGP read and write request 
queue that contains requests from tiie second AGP bus 162 and is meant for the first 
AGP bus 107 or the third AGP bus 164. Similarly, there is another second AGP read 
and write request queue in the opposite direction wliich contains peer-to-peer requests 
from the third AGP bus 164 directed toward the second AGP bus 162. The 
bi-directionality between tiie furst AGP interface 240, the second AGP interface 250, 
and the third AGP interface 270 can be facilitated by use of data buses 241, 243 and 
245 as shown in Figure 4e. 
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The overall flow control logic 260 of the preferred embodunent must be 
cognizant of the peer-to-peer address ranges supported by each AGP bus. The overall 
flow control logic 260 must be able to recognize from the address of the request 
whether or not it is a peer-to-peer or a bridge-to-host access. For example, when there 

5 is a request in the second AGP read and write request queue 254, the overall flow 
control logic 260 determines whether the request is a peer-to-peer transaction or a 
bridge-to-host access. If the request is a peer-to-peer transaction, then the request is 
sent to the third AGP read and write request queue 274 via bus 243. Otherwise, the 
request is sent to the first AGP read and write request queue 244. Likevdse, when 

10 there is a request in the third AGP read and write request queue 274, the overall flow 
control logic 260 determines whether the request is a peer-to-peer transaction or a 
bridge-to-host access. If the request is a peer-to-peer transaction, the request is sent to 
the second AGP read and write request queue 254 via bus 243. Otherwise, the request 
is sent to the first AGP read and write request queue 244 via bus 243. This mettiod is 

15 described in the flow diagram in Figures 17 and 18. 

The flow of data is illustrated in Figures 17-20. The discussion of Figures 17- 
20 is foimd later in this specification. It should be noted however that the process of 
actually transferring the request from the second AGP queues to the thurd AGP 
queues, or vice versa, is similar to the transfer of request from the second AGP queue 
20 or the third AGP queue to the first AGP queue. If the request is a read request, then 
the read request is transferred to the other queue if there is space in that other queue. 
If the request is a write request, then the write request must be transferred and also the 
write data must also be transferred. 
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When there is a read request (originated from the third AGP bus) that needs to 
be run on the second AGP bus 162, the second AGP read and write request queue 254 
is responsible for initiating the read transaction on the bus. Once the data has been 
returned to the second AGP read data return queue 252, the data is then transferred 

5 internally to the third AGP read data return queue 272. Likewise, when there is a read 
request (originated from the second AGP bus) that needs to be run on the third AGP 
bus, the third AGP read and write request queue is responsible to initiate the read 
transaction on the bus. Once the data has been returned to the thurd AGP read data 
retum queue 272, the data is then transferred internally to the second AGP read data 

10 retum queue 252. This flow is similar to a read request from the first AGP interface 
240 and the transfer of the read reply to the second AGP interface 250 or to the third 
AGP interface 270 as illustrated in Figures 1 1, 14 and 15. 

When there is a write request originating form the third AGP bus 164 that 
must be sent over the second AGP bus 162, the second AGP read and write request 

15 queue 254 is responsible for initiating the write transaction on the bus. The 
corresponding write data will be available in the second AGP write data queue 256. 
Likewise, when there is a write request originating form the second AGP bus 162 that 
must be sent over the third AGP bus 164, the third AGP read and write request queue 
274 is responsible for initiating the write transaction on the bus. The corresponding 

20 write data will be available in the third AGP write data queue 276. This flow is 
similar to the completion of a write request from the first AGP interface 240 as 
illustrated in Figure 1 1 . 
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Figure 5 shows the block diagram of the PCI interface 161 of the AGP to AGP 
bridge 160 of the present invention. The PCI interface 161 is connected to the AGP 
bus 107. The PCI mterface 161 has a first PCI master/target mterface 238 that 
connects the AGP bus 107 to a furst PCI target state machine 282 and a first PCI 
5 master state machine 284. The first PCI target state machine 282 is connected to a 
second PCI master state machine 288 and a third PCI target state machine 296. The 
first PCI master state machine 284 is connected to a second PCI target state machine 
286 and a third PCI target state machine 298 as shown in Figure 5. The second PCI 
target state machine 286 and the second PCI master state machine 288, in tum, are 
10 connected to a second PCI master/target arbiter 290. Likewise, the third PCI target 
state machine 296 and the third PCI master state machine 298 are connected to the 
third PCI master/target arbiter 292. 

Operation of the Second and Third Read and Write Request Queue 

When the AGP device on either the second AGP bus 162 or the third AGP bus 

15 164 needs to send a request to the AGP to AGP bridge 160, they will first assert the 
Request (REQ#) line. When the corresponding queues (second read and write request 
queue 254 and third read and write request queue 274) have space to accept this 
request, the AGP to AGP bridge 160 will assert a Grant (GNT#) and the appropriate 
bits in the PCI status register (not shown). The AGP device will start transferring the 

20 request by asserting PIPE# or using the side-band addressing mentioned previously. 
The address, command, and length is stored in the second read and write request 
queue 254 and third read and write request queue 274. The AGP to AGP bridge 160 
can do this simultaneously for both buses. When the master has completed 
transferring all the requests it has, the AGP to AGP bridge 160 will process the write 
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commands. The master will need to get write d^^ta into the AGP to AGP bridge 160 
so that, when the core logic 104 requests the data, the master will have the data 
available. The master will assert GNT# and set a status bit indicating a write request 
on the corresponding bus. The master will store the write data in the write data 
5 queues (either the second write data queue 256 or the third write data queue 276, 
depending upon whether the master is connected to the second AGP bus 162 or the 
third AGP bus 164, respectively). 

The read and write request queues (244, 254, 274) will do all the ordering 
inside its queue block. Each read and write request queue will have a separate queue 
10 for high priority reads and writes in order to allow the queue to bypass the low priority 
requests. The read and write request queues (244, 254, 274) will also accommodate 
other ordering rules such as writes bypassing reads, fence and flush. 

Operation of the Second and Third Write Data Queues 

When the AGP to AGP bridge 160 executes a write cycle on the AGP buses, it 
15 stores the write data in the write data queues (246, 256, and 276). The write data will 
be stored in the same order in which it was received on the bus. However, it may not 
be practical to allocate space for the maximum allowable length of v^Tite accesses for 
the situation where all accesses in the queue are writes. Therefore, in the preferred 
embodiment of the present invention, write data queue space will be limited and the 
20 AGP to AGP bridge 160 can only run write cycles on the first AGP bus 107 when the 
AGP to AGP bridge 160 has space in the first write data queue 246 to accept the 
entire write data. 
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operation of the First Read and Write Request Queue 

In this scenario, the first AGP bus 107 is affected and the AGP to AGP bridge 
160 is a master. The AGP to AGP bridge 160 has to wait for a GNT# from the core 
logic 104 (or, in an alternate embodiment of the present invention, other AGP bridges) 

5 before the AGP to AGP bridge 160 can start transferring requests to the core logic 
104. The first read and write request queue 244 will accept requests from the second 
read and write request queue 254 and the third read and write request queue 274. The 
AGP interface 230 needs to follow all of the AGP ordering rules inside the first read 
and write request queue 244. In the preferred embodiment of the present invention, 

10 the first read and write request queue 244 will use some fair algorithm to service the 
second read and write request queue 254 and the third read and write request queue 
274. Strict altemation is one option algorithm. However, it may be possible for the 
first read and write request queue 244 to treat all accesses inside of itself equally. 
What this means is that, the first read and write request queue 244 will allow all writes 

15 to bypass all reads regardless of whether the write came from the second AGP bus 162 
or the third AGP bus 164. The first read and write request queue 244 will also block 
all future writes from bypassing reads if there is a fence access. This technique is 
non-optimal since accesses from the third AGP bus 164 do not care about ordering 
with accesses from second AGP bus 162. However, the implementation of this block 

20 will be simpler with this assumption. When requests are transferred from the second 
read and write request queue 254, and the third read and write request queue 274 to 
the first read and write request queue 244, the originating bus number has to be kept 
track of, in order to be able to return the data to the right bus. 
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operation of the First Write Data Queue 

When a write request is transferred from the second read and write request 
queue 254 or the third read and write request queue 274 to the first read and write 
request queue 244, the corresponding write data must be transferred from the second 

5 write data queue 256 or the third write data queue 276 to the first write data queue 
246. If the write data is not available in the second write data queue 256 or the third 
write data queue 276 yet, then the write access should not be moved to the first write 
data queue 246. This might stall other accesses from proceeding through them even if 
they might have been capable of doing so. However, under this methodology, when 

10 the access is run on the first AGP bus 107 and the core logic 104 needs the write data, 
the computer system will not have to stall the operation with excessive wait states 
which would be detrimental to performance. 

Operation of the First Read Data Retum Queue 

When the core logic 104 responds to a read request, the data is kept in the first 
15 read data retum queue 242. From there, the data is matched up with the originating 
request. The data is transferred to the corresponding second read data retum queue 
252 or the third read data retum queue 272. Then the request can be retired from the 
first read and write request queue 244. 

Operation of the Second and the Third Data Retum Queues 
20 When there is read data in either the second read data retum queue 252 or the 

third read data retum queue 272, the AGP to AGP bridge 160 asserts GNT# at the first 
opportunity, and then starts to transfer data to the AGP device that issued the read 
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request. The random data that is returned on a fence operation is also returned 
through the second read data return queue 252 or the third read data return queue 272. 

Operation of the Overall Flow Control Logic 

The flow control logic 260 is responsible for control of data between all the 
5 other blocks in the AGP to AGP bridge 160. Requests can be transferred from the 
second read and write request queue 254 and the third read and write request queue 
274 to the first read and write request queue 244 only when there is space in the queue 
in the first read and write request queue 244. The second AGP interface 250 and the 
third AGP interface 270 can accept requests from the second AGP bus 162 and the 
10 third AGP bus 164, respectively, only when there is space in the second read and 
write request queue 254 and the third read and write request queue 274, respectively. 
Th&flow control logic 260 generally controls the flow from the second AGP interface 
250 and the third AGP interface 270 into the first AGP interface 240. The flow 
control logic 260 also controls the flow of data back from the first AGP interface 240 
15 to the second AGP interface 250 and the third AGP interface 270. The flow control 
logic 260 also controls the flow between the AGP to AGP bridge 160 and the AGP 
interfaces (240, 250 and 270) on their respective AGP buses (107, 162 and 164). 

The request operation of the second interface target and arbiter 258 is 
illustrated in Figure 6. The operation is started in step 602. First, a check is made if 
20 there is a request on the second AGP bus 162, step 604. If no request is present, step 
604 is repeated until the result is positive (i.e., YES). If a request is present on the 
second AGP bus 162, then the request is added to the second read and write request 
queue 254, step 606. Finally, in step 608, the requests are reordered according to the 
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appropriate ordering rules. In the preferred embodiment of the present invention, the 
ordering rules are a predefined set of ordering rules. However, it is within the scope 
of the present invention to utilize a dynamically created set of ordering rules based 
upon conditions at that instant time. 

5 The reply operation of the second interface target and arbiter 258 is illustrated 

in Figure 7. The operation is started in step 702. First, a control signal to start a 
transaction is received fi-om the flow control logic 260, step 704. Next, in step 706, 
three sub-steps take place. First, an arbitration is performed and a read reply 
transaction is started. Second, data is retrieved from the read data return queue 256. 

10 Third, wait states are inserted, if necessary, when instructed by the flow control logic 
260. 

The request operation of the third interface target and arbiter 278 is illustrated 
in Figvire 8. The operation is started in step 802. First, a check is made if there is a 
request on the third AGP bus 164, step 804. If no request is present, step 804 is 

15 repeated until the resuh is positive (i.e., YES). If a request is present on the third 
AGP bus 164, then the request is added to the third read data retum queue 272, step 
806. Finally, in slep 808, the requests are reordered according to the appropriate 
ordering rules. In the preferred embodiment of the present invention, the ordering 
rules are a predefined set of ordering rules. However, it is within the scope of the 

20 present invention to utilize a dynamically created set of ordering rules based upon 
condition at that instant of time. 

The reply operation of the third interface target and arbiter 278 is illustrated in 
Figure 9. The operation is started in step 902. First, a control signal to start a 
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transaction is received from the flow control logic 260, step 904. Next, in step 906, 
three sub-steps take place. First, an arbitration is performed and a read reply 
transaction is started. Second, data is retrieved from the third read and write request 
queue 274. Third, wait states are mserted, if necessary, when instructed by the flow 
5 control logic 260. 

The request operation of the first AGP bus 107 is illustrated in Figure 10. The 
operation is started in step 1002. First, in step 1004, a check is made to determine if a 
request is in the first read and write request queue 244. If a request is present, (i.e., 
the resuh is YES), then step 1006 is undertaken. In step 1006, a check is made to 

10 determine if additional request can be queued to the first interface target and arbiter 
248. It should be noted that the total number of requests that can be queued at any 
. one- time is programmed into each AGP master during the configuration setup. If 
fiirther requests can be queued, then step 1008 is performed. During step 1008, an 
arbitration is performed and the requests are queued. In addition, in step 1008, the 

1 5 status of the request in the queue is changed if so requested. 

The reply operation of the first AGP bus 107 is shown in Figure 11. The 
operation is started in step 1 102. First, a check is made to determine if there is a reply 
in the first AGP bus 107, step 1 104. If so, then step 1 106 is performed where a chieck 
is made to determine if the reply is a write statement. If so, step 1108 is performed, 
20 otherwise, execution jumps to step 1110. In step 1 108, data is supplied from the fu:st 
write data queue 246. The data is then retired from tiie first read and write request 
queue 244 and the first read data retiim queue 242. In step 1 1 10, a check is made to 
determine if the reply is a read statement. If so, execution continues onto step 1112, 
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otherwise, execution jumps to step 1 120. In step 1 1 12, the data is stored in the first 
read data return queue 242 and the corresponding read request is moved to the first 
read data return queue 242. Further, in step 1112, the flow control logic 260 is 
triggered to start moving this data towards either the second AGP bus 162 or the third 
AGP bus 164. Next, in step 1114, wait states at a subsequent block are inserted if the 
first read data return queue 242 is fiill or is less than 32 bytes while in 2x mode or 16 
bytes while in Ix mode until access has been completed on the first AGP bus 107. 
Thereafter, in step 1 1 16, a check is made to see if an RBF# has been asserted. If so, 
then step 1118 is executed wherein the buffer space that was reserved for RBF# 
spillover is utilized and an ASAP wait state is inserted on a subsequent boundary per 
the AGP specification. If not, execution skips to step 1 120. In step 1 120, a check is 
made to determine if the reply is a fence. If so, then, m step 1122, the access is 
completed and the flow control logic 260 is triggered accordingly. 

Figure 12 illustrates the four major state machines implemented within the 
flow control logic 260. The flow control logic 260 has several parallel and somewhat 
independent functions. E^ch of these functions will be described and illustrated 
below. 

Referring again to Figure 12, the first state machine 1300 requests a transfer 
from either the second read and write request queue 254 or the third read and write 
request queue 274 to the first read and write request queue 244. The second state 
machine 1400 is the control for the RBF#. The third state machine 1500 is for read 
data transfers from the first read data return queue 242 to either the second read data 
return queue 252 or the third read data return queue 272. The fourth state machine 
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1202 controls the information to the second interface target and arbiter 258 and the 
third interface target and arbiter 278 when a read access is completing on either of 
those buses, respectively. 

The fonction of the first state machine 1300 is shown in Figure 13. The 
5 operation is started in step 1302. First, a check is made to determine if the requested 
transfer is in the second read and write request queue 254. If not. execution is jumped 
to step 1324 to perform the same check with regard to the third read and write request 
queue 274. If the requested transfer is in the second read and write request queue 254, 
then execution continues to step 1306 where a check is made to determine if the 
10 requested transfer is a write. If not, then execution jumps to step 1314, otherwise, 
execution continues to step 1308. In step 1308, a check is made to determine if the 
. write was complete in the second AGP bus 162. If so, then execution jumps to step 
1324, otherwise, execution continues on to step 1310 where another check is made to 
determine if there is space in the first write data queue 246 for the entire access. If 
15 not, then execution jumps to step 1324, otherwise, execution continues to step 1312 
wherein the write cycle is executed on the second AGP bus 162 and the write data is 
stored in the first write data queue 246. The request is then marked as completed on 
the second AGP bus 162 to complete step 1312. 

In step 1314, a check is made to determine if space is available in the first read 
20 and write request queue 244 of the first AGP bus 107. If not, execution is looped 
back to step 1304, otherwise, execution continues onto step 1316. In step 1316, a 
check is made to determine if the request is a write. If not, execution is jumped to 
step 1322, otherwise, execution continues on to step 1318 where a check is made to 
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determine if there is space in the first write data queue 246. If not, then execution is 
looped back to step 1304, oflierwise, execution continues on to step 1320 wherein the 
data and request are transferred and the first AGP queues are reordered according to 
the appropriate ordering rules. Execution then jumps to step 1324. In step 1322, to 
which execution jumps if the request is not a write, the request is transferred and the 
first AGP bus 107 queue is reordered according to the appropriate ordering rules. 

Steps 1324 through 1342 are similar to steps 1304 through 1322 only that, in 
this case, the AGP bus affected is the third AGP bus 164 instead of tiie second AGP 
bus 162. There are some minor differences, however. 

In step 1324, a check is made to determine if the request is in the third read 
and write request queue 274. If not, execution is looped back to the start at step 1304, 
otherwise, execution continues to step 1326. In step 1326, a check is made to 
determine if tiie request is a write statement. If not, execution is jumped to step 1334, 
otherwise, execution continues on to step 1328 where a check is made to determine if 
the write was complete in the tiiird AGP bus 164. If so, then execution is jumped to 
step 1334, otherwise, execution continues on to step 1330 where a check is made to 
determine if space is available in tiie first write data queue 246 for tiie entire access. 
If not, execution is looped back to step 1324, otherwise, execution continues on to 
step 1332 where tiie write cycle is executed on tiie tiiird AGP bus 164 and the write 
data is stored in tiie first write data queue 246. The request is tiien marked as 
completed on the third AGP bus 164 to complete step 1332. 

In step 1334, a check is made to determine if space is available in the first read 
and write request queue 244. If not, execution is looped back to step 1324, otiierwise. 
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execution continues on to step 1336 where a check is made to determine if the request 
is a write. If not, execution is jumped to step 1342, otherwise, execution continues on 
to step 1338 where a check is made to determine if space is available on the first write 
data queue 246. If not, execution is looped back to step 1324, otherwise, execution 

5 continues on to step 1340 where the data and the request is transferred to the 
appropriate queues of the first AGP bus 107 and those queues are reordered according 
to the ordering rules. Execution is then looped back to the start at step 1304. If the 
request is a not write, then, as mentioned before, step 1342 is executed wherein the 
request is transferred to the appropriate queue in the first AGP bus 107 and those 

10 queues are reordered according to the appropriate ordering rules. 

The fiinction of the second state machine 1400 is illustrated in Figure 14. 
Referring now to Figure 14, the operation of the RBF# control is accompUshed in the 
following steps. The process is started in step 1402. First, in step 1404, a check is 
made to determine if the next read on the first read and write request queue 244 is 

15 small enough to fit within the internal buffer space in the AGP to AGP bridge 160. If 
so, then execution is looped back to step 1404, otherwise, execution continues on to 
step 1406 where a check is made to determine if the next read request is fi-om the 
second AGP bus 162. If not, execution is jumped to step 1418 where the same check 
is made for the third AGP bus 164. Otherwise, execution continues on to step 1408 

20 where a check is made to determine if the RBF# on the second AGP bus 162 has been 
asserted. If not, then execution is looped back to step 1404. Otherwise, execution 
continues on to step 1410 where the RBF# for the first AGP bus 107 is asserted. 
Next, in step 1412, a check is made to determine if the RBF# of the second AGP bus 
162 has been de-asserted. If not, then step 1412 is repeated. If so, then execution 
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continues on to step 1416 wherein the RBF# for the first AGP bus 107 is de-asserted. 
Execution is then looped back to step 1404. 

If the next read request was not from the second AGP bus 162, then it must 
have come from the third AGP bus 164. In that case, step 1418 is performed and, 

5 upon testing positive, a check is made to determine if the RBF# of the third AGP bus 
164 has been asserted, step 1420. If not, execution is looped back to step 1404, 
otherwise, execution continues to step 1422 where the RBF# for the first AGP bus 
107 is asserted. Next, in step 1424, a check is made to determine if the RBF# of the 
thu-d AGP bus 164 has been de-asserted. If not, step 1424 is repeated. Otherwise, in 

10 step 1426, the RBF# of the first AGP bus 107 is de-asserted and execution is looped 
back to step 1404. 

The function of the third state machine 1500 is illustrated in Figure 15. Figure 
15 shows a flow diagram of a read data transfer from the second AGP bus 162 or the 
third AGP bus 164 to the first AGP bus 107. The process starts in step 1502. Next, in 

15 step 1504, a check is made to determine if there is a reply in the first read data return 
queue 242 (even if the entire read data has not yet arrived). If so, then execution 
proceeds to step 1506 where a check is made to determine if the reply is for the 
second AGP bus 162. If not, execution shifts to step 1512 in order to handle a transfer 
from the third AGP bus 164. Otherwise, execution proceeds to step 1508 where a 

20 check is made to determine if there is sufficient space in the second read data retum 
queue 252. If so, execution proceeds to step 1510 where the data is transferred (as it 
comes in) to the second read data retum queue 252. Also in step 1510, the second 
interface target and arbiter 258 is triggered to start a transaction on the second AGP 
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bus 162 and to complete the transfer of the entire requested size and, if the second 
read data return queue 252 becomes full, to wait for it to empty. 

If the reply is not for the second AGP bus 162. then it must be for the third 
AGP bus 164, prompting step 1512 to be executed. In step 1512. a check is made to 
verify that the reply is for the third AGP bus 164. If so, then step 1514 is executed 
wherein a check is made to determine if there is sufficient space available in the third 
read data return queue 272. If so. then execution proceeds to step 1516. where the 
data is transferred (as it comes in) to the third read data return queue 272. Also in step 
1516, the third interface target and arbiter 278 is triggered to start a transaction on the 
third AGP bus 164 and to complete the transfer of the entire requested size and, if the 
third read data return queue 272 becomes fiill, to wait for it to empty. 

Handling Peer-to-Peer Transactions 

If the AGP to AGP bridge 160 is to handle peer-to-peer transactions, several 
additional steps of the method of the present invention must be taken. For example. 
Figure 17 illustrates the steps needed if there is a request in the second AGP read and 
write request queue 254 (see Figure 4e). First, the peer-to-peer enabled processing 
starts in step 1702. Next, in step 1704, a check is made to determine if there is a 
request in the second AGP read and write request queue 254. If no request is present 
(i.e., the result of step 1704 is "No"), then step 1704 is repeated until a request is 
present. If a request is present, then a check is made to determine if the request is a 
peer-to-peer request, step 1706. If the request is a peer-to-peer request (i.e., the result 
of step 1706 is "Yes"), then the request is transferred to the third AGP read and write 
request queue 274 of Figure 4e in step 1708. If the request is not a peer-to-peer 
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request (i.e., the result of step 1706 is "No"), then the request is transferred to the first 
AGP read and write request queue 244 in step 1710. 

The situation of a request in the third AGP interface 270 is similar to that of 
the second AGP interface 250. For example. Figure 18 illustrates the steps needed if 
there is a request in the second AGP read and write request queue 274 (see Figure 4e). 
First, the peer-to-peer enabled processing starts in step 1802. Next, in step 1804, a 
check is made to determine if there is a request in the third AGP read and write 
request queue 274. If no request is present (i.e., the result of step 1804 is "No"), then 
step 1804 is repeated until a request is present. If a request is present, then a check is 
made to determine if the request is a peer-to-peer request, step 1806. If the request is 
a peer-to-peer request (i.e., the resuh of step 1806 is "Yes"), then the request is 
. transferred to the second AGP read and write request queue 254 of Figure 4e in step 
1808. If the request is not a peer-to-peer request (i.e., the result of step 1806 is 
"No"), then the request is transferred to the first AGP read and write request queue 
244 in step 1810. 

In the case of peer-to-peer enabled embodiments AGP to AGP bridge 160 of 
the present invention, replies are handled expeditiously. Recall that in die peer-to- 
peer enabled embodiment of the AGP to AGP bridge of the present invention the 
second AGP read and write request queues have two queues in order to enable 
bi-directionality. In the case of peer-to-peer replies, these are handled in a two step 
operation as shown in Figure 19. The process starts in step 1902. In step 1904, a 
check is made to determine if a reply is in the second AGP read data return queue 252 
(see Figure 4e). If not, step 1904 is repeated until a reply is in the queue. Otherwise, 
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the reply is transferred to the third AGP read data queue 272. Similarly, peer-to-peer 
replies in the third AGP read data return queue is handled according to Figure 20. 
The process starts in step 2002. A check is made in step 2004 to determine if a reply 
is in the third AGP read data return queue 272 (see Figure 4e). If not, step 2004 is 
repeated until a reply is in the queue. Otherwise, the reply is transferred to the second 
AGP read data return queue in step 2006. 

Peer-to-peer requests are handled a similar manner to replies. For example, 
requests in the second AGP write data queue 256 (see Figure 4e) that are peer-to-peer 
are handled according to Figure 21. The process starts at step 2102. In step 2104, a 
check is made to determine if a request is in the second AGP write data queue 256 
(see Figure 4e). If not, step 2104 is repeated until a request is in the queue. 
. Otherwise, the request is transferred to the third AGP write data queue 276 in step 
2106. Similarly, requests in the third AGP write data queue 276 (see Figure 4e) that 

are peer-to-peer are handled according to Figure 22. The process starts at step 2202. 

In step 2204, a check is made to determine if a request is in the third AGP write data 

queue 276 (see Figure 4e). If not, step 2204 is repeated until a request is in the queue. 

Otherwise, the request is transferred to the second AGP write data queue 256 in step 

2206. 

The present invention, therefore, is well adapted to cany out the objects and 
attain the ends and advantages mentioned, as well as others inherent therein. While 
the present invention has been depicted, described, and is defmed by reference to 
particular preferred embodiments of the invention, such references do not imply a 
limitation on the invention, and no such limitation is to be inferred. The invention is 
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capable of considerable modification, alternation, and equivalents in form and 
function, as will occur to those of ordinary skill in the pertinent arts. The depicted and 
described preferred embodiments of the invention are exemplary only, and are not 
exhaustive of the scope of the invention. Consequently, the invention is intended to 
5 be limited only by the spirit and scope of the appended claims, giving full cognizance 
to equivalents in all respects. 
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